Fix documentation inconsistencies #2043
Conversation
|
|
command.go
Outdated
| @@ -568,7 +568,7 @@ Additional Commands:{{range $cmds}}{{if (and (eq .GroupID "") (or .IsAvailableCo | |||
| Flags: | |||
| {{.LocalFlags.FlagUsages | trimTrailingWhitespaces}}{{end}}{{if .HasAvailableInheritedFlags}} | |||
|
|
|||
| Global Flags: | |||
| Flags inherited from parent commands: | |||
There was a problem hiding this comment.
I'm not a fan of this change: while you're technically correct (what we're calling global flags are just flags inherited from the top level command), in spirit, they are global flags.
This would be a pretty confusing change for people who've used cobra for years.
There was a problem hiding this comment.
They are not necessarily inherited from top level command, just a parent command, which makes the "Global Flags" statement even more confusing when having multiple levels of sub commands.
I would argue that it's more confusing calling them something they really are not, i.e. "Global Flags", then calling them what they actually are, technically and factually. Whether they may be global "in spirit" or not, I think actual usage is more important, and, at least from our point of view, they are not treated as global for sure.
I guess a compromise would be something like "Global flags inherited from parent command" or something like that.
There was a problem hiding this comment.
Hmmm that's a very fair point: this is probably one of those legacy inconsistencies that has popped up as we've expanded the command / flag system. It's not really global, like you said, since it is inherited from some parent.
Anyone else have opinions here.
There was a problem hiding this comment.
The point is valid but I don’t think it justifies changing a formulation that tools have been using for years.
In fact, I wonder if many tools aren’t putting the inherited flags mostly on the root command which would make them global flags so although this printout is not technically correct, it is in practice the right thing, and what existing tools are expecting
There was a problem hiding this comment.
It's fair to say that this change would be somewhat of an inconvenience for developers using the tool and the cost may be a bit high for this change. I'll revert the print out because of that in this PR.
I think it's good though to consider that application developers aren't the end users for cobra. The end users are the ones actually using the application and the ones that would actually read the help documentation. In our case, the "Global Flags" print has actually caused a bit of confusion.
Anyway, dealing with this slight inconsistency between markdown and help func is the point of this PR and I'll revert it back for this. How this is worded would probably a discussion to have at some other point.
| @@ -31,15 +31,15 @@ func printOptions(buf *bytes.Buffer, cmd *cobra.Command, name string) error { | |||
| flags := cmd.NonInheritedFlags() | |||
| flags.SetOutput(buf) | |||
| if flags.HasAvailableFlags() { | |||
| buf.WriteString("### Options\n\n```\n") | |||
| buf.WriteString("### Flags\n\n```\n") | |||
There was a problem hiding this comment.
Changing Options to Flags in the markdown docs seems fine. Although this introduces another inconsistency between what we internally call "options" in the docs generation. I.e., look at what we do for yaml docs:
Line 43 in 8b1eba4
so this makes me abit hesitant since that struct is a public API and I would rather not change that too
There was a problem hiding this comment.
Yes, I see there are more inconsistencies there, but I think it would be best to handle those in another branch. Especially when there's a function that may need to change.
There was a problem hiding this comment.
I also discovered that the inconsistencies are present in the man tree generation as well:
Lines 187 to 200 in a0a6ae0
This fixes inconsistencies between the command help template and what is being generated as markdown.
Currently, the help template prints "Flags" and "Global Flags" when printing help for flags, while in the markdown, the two are printed as "Options" and "Options inherited from parent commands".
This Pull Request fixes this inconsistency, so that they both print the same. As for the actual formulation, I opted for using "Flags" and "Flags inherited from parent commands". In the latter case, I think this formulation actually represents it better than the previous "Global flags", since flags printed there are in fact inherited and not necessarily global in scope. This is, of course, up for discussion what to actually use.
Edit: Excuse the typo in the second commit message 😁